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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides a description of the UTRAN RNC-Node B (lub) interface user plane protocols for 
Common Transport Channel data streams as agreed within the TSG-RAN working group 3. 

NOTE: By Common Transport Channel one must understand RACH, FACH/PCH, DSCH, USCH and HS- 
DSCH. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[2] 3GPP TS 25 .402: "Synchronisation in UTRAN, Stage 2" . 

[3] 3GPP TS 25.302: "Services provided by the Physical Layer". 

[4] 3GPP TS 25.221: "Physical channels and mapping of transport channels to physical channels 

(TDD)". 

[5] 3GPP TS 25 .2 11 : "Physical channels and mapping of transport channels onto physical channels 

(FDD)". 

[6] 3GPP TS 25.433: "UTRAN lub interface NBAP signalHng". 

[7] 3GPP TS 25 .225 : "Physical layer - Measurements (TDD)" . 

[8] 3GPP TS 25.331: "Radio Ressource Control (RRC) protocol specification". 

[9] 3GPP TS 25.321: "Medium Access Control (MAC) protocol specification". 

[10] 3GPP TS 25.214: " Physical layer procedures". 

[II] 3GPP TS 25 .40 1 : "UTRAN overall description" . 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions in [2] and the following apply: 

Transport Connection: service provided by the transport layer and used by Frame Protocol for the delivery of FP PDU 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations in [2] and the following apply: 

CFN Connection Frame Number 

CRC Cyclic Redundancy Checksum 

CRCI CRC Indicator 

DCH Dedicated Transport Channel 

DL Downlink 

DRT Delay Reference Time 

DSCH Downlink Shared Channel 

FP Frame Protocol 

FSN Frame Sequence Number 

FT Frame Type 

HSDPA High Speed Downlink Packet Access 

HS-DSCH High Speed Downlink Shared Channel 

LTOA Latest Time of Arrival 

MFN Multicast Frame Number 

PC Power Control 

PDSCH Physical Downlink Shared Channel 

PUSCH Physical Uplink Shared Channel 

QE Quality Estimate 

TB Transport Block 

TBS Transport Block Set 

TFI Transport Format Indicator 

TNL Transport Network Layer 

ToA Time of Arrival 

ToAWE Time of Arrival Window Endpoint 

ToAWS Time of Arrival Window Startpoint 

TTI Transmission Time Interval 

UL UpUnk 

USCH Uplink Shared Channel 

3.3 Specification Notations 

For the purposes of the present document, the following notations apply: 

[FDD] This tagging of a word indicates that the word preceding the tag "[FDD]" applies only to FDD. 

This tagging of a heading indicates that the heading preceding the tag "[FDD]" and the section 
following the heading applies only to FDD. 

[TDD] This tagging of a word indicates that the word preceding the tag "[TDD]" applies only to TDD, 

including 7.68Mcps TDD, 3.84Mcps TDD and 1.28Mcps TDD. This tagging of a heading 
indicates that the heading preceding the tag "[TDD]" and the section following the heading applies 
only to TDD, including 7.68Mcps TDD, 3.84Mcps TDD and 1.28Mcps TDD. 

[7.68Mcps TDD] This tagging of a word indicates that the word preceding the tag '[7.68Mcps TDD]' applies only to 
7.68Mcps TDD. This tagging of a heading indicates that the heading preceding the tag '[7.68Mcps 
TDD]' and the section following the heading applies only to 7.68Mcps TDD. 

[3.84Mcps TDD] This tagging of a word indicates that the word preceding the tag '[3.84Mcps TDD]' applies only to 
3.84Mcps TDD. This tagging of a heading indicates that the heading preceding the tag '[3.84Mcps 
TDD]' and the section following the heading applies only to 3.84Mcps TDD. 

[ 1 .28Mcps TDD] This tagging of a word indicates that the word preceding the tag " [ 1 .28Mcps TDD] " applies only 
to 1.28Mcps TDD. This tagging of a heading indicates that the heading preceding the tag 
"[L28Mcps TDD]" and the section following the heading applies only to 1.28Mcps TDD. 

[FDD - ...] This tagging indicates that the enclosed text following the "[FDD - " applies only to FDD. 

Multiple sequential paragraphs applying only to FDD are enclosed separately to enable insertion of 
TDD specific (or common) paragraphs between the FDD specific paragraphs. 
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[TDD - . . .] This tagging indicates that the enclosed text following the "[TDD - " applies only to TDD, 

including 7.68Mcps TDD, 3.84Mcps TDD and 1.28Mcps TDD. Multiple sequential paragraphs 
applying only to TDD are enclosed separately to enable insertion of FDD specific (or common) 
paragraphs between the TDD specific paragraphs. 

[7.68Mcps TDD - ...] This tagging indicates that the enclosed text following the "[7.68Mcps TDD - " applies only 
to 7.68Mcps TDD. Multiple sequential paragraphs applying only to 7.68Mcps TDD are enclosed 
separately to enable insertion of FDD and TDD specific (or common) paragraphs between the 
7.68Mcps TDD specific paragraphs. 

[3.84Mcps TDD - ...] This tagging indicates that the enclosed text following the "[3.84Mcps TDD - " applies only 
to 3.84Mcps TDD. Multiple sequential paragraphs applying only to 1.28Mcps TDD are enclosed 
separately to enable insertion of FDD and TDD specific (or common) paragraphs between the 
3.84Mcps TDD specific paragraphs. 

[1.28Mcps TDD - ...] This tagging indicates that the enclosed text following the "[1.28Mcps TDD - " applies 
only to 1.28Mcps TDD. Multiple sequential paragraphs applying only to 1.28Mcps TDD are 
enclosed separately to enable insertion of FDD and TDD specific (or common) paragraphs 
between the 1.28Mcps TDD specific paragraphs. 

Procedure When referring to a procedure in the specification the Procedure Name is written with the first 

letters in each word in upper case characters followed by the word "procedure", e.g. Node 
Synchronisation procedure. 

Frame When referring to a control or data frame in the specification the CONTROL/DATA FRAME 

NAME is written with all letters in upper case characters followed by the words "control/data 
frame", e.g. TIMING ADJUSTMENT control frame. 

IE When referring to an information element (IE) in the specification the Information Element Name 

is written with the first letters in each word in upper case characters and all letters in Italic font 
followed by the abbreviation "IE", e.g. Frame Type IE. 

Value of an IE When referring to the value of an information element (IE) in the specification the "Value" is 

written as it is specified in subclause 6.2.7 or 6.3.3 enclosed by quotation marks, e.g. "0" or "255". 



4 General aspects 

4.1 Common Transport Channel Data Stream User Plane 
Protocol Services 

Common transport channel provides the following services: 

Transport of TBS between the Node B and the CRNC for common transport channels. 
Support of transport channel synchronisation mechanism. 
Support of Node Synchronisation mechanism. 

4.2 Services expected from the Data Transport Network layer 

The following services are expected from the transport layer: 

Delivery of Frame Protocol PDUs. 

In sequence delivery is not required. However, frequent out-of-sequence delivery may impact the performance and 
should be avoided. 
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4.3 



Protocol Version 



This revision of the specification specifies version 1 of the protocols. 



Data Streams User Plane Procedures 



5.1 



Data Transfer 



5.1.1 



RACH Channels 



Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC. Data Transfer 
procedure consists of a transmission of Data Frame from Node B to CRNC. 



Node B 



CRNC 



RACH DATA FRA^jlE 



Figure 1 : RACH Data Transfer procedure 

5.1.2 CPCH Channels [FDD] 

Void. 

5.1 .3 Secondary-CCPCH related transport Channels 

For the FACH transport channel, a Data Transfer procedure is used to transfer data from CRNC to Node B. Data 
Transfer procedure consists of a transmission of Data Frame from CRNC to Node B. 



Node B 



CRNC 



FACH DATA FRAME 



Figure 3: FACH Data Transfer procedure 

For the PCH transport channel, a Data Transfer procedure is used to transfer data from CRNC to Node B. Data Transfer 
procedure consists of a transmission of Data Frame from CRNC to Node B. 
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Node B CRNC 



^PCH DATA FRAME 



Figure 4: PCH Data Transfer procedure 

In this case the PCH DATA FRAME may also transport information related to the PICH channel. 

If the Node B does not receive a valid FP frame in a TTI, it assumes that there is no data to be transmitted in that TTI 
for this transport channel. For the FACH and PCH transport channels, the TFS shall never define a Transport Block 
Size of zero bits. 

If the Node B is aware of a TFI value corresponding to zero bits for this transport channel, this TFI is assumed. When 
combining the TFI's of the different transport channels, a valid TFCI might result and in this case data shall be 
transmitted on the Uu. 

If the Node B is not aware of a TFI value corresponding to zero bits for this transport channel or if combining the TFI 
corresponding to zero bits with other TFI's results in an unknown TFI combination, the handling as described in the 
following paragraph shall be applied. 

At each frame, the Node B shall build the TFCI value of each secondary-CCPCH according to the TFIs of the transport 
channels multiplexed on this secondary-CCPCH and scheduled for that frame. [FDD - In case the Node B receives an 
unknown TFI combination, no pilot bits, TFCI bits or Data bits shall be transmitted.] [TDD - In case the Node B 
receives an unknown TFI combination, it shall apply DTX, i.e. suspend transmission on the corresponding S-CCPCH - 
except if this S-CCPCH provides the "beacon function", in which case the Node B shall maintain the physical layer 
transmission as specified in TS 25.221]. 



If the Node B does not receive a valid FP frame in a TTI or a frame without paging indication information, it assumes 
that no UE's have to be paged on the Uu in this TTI. In this case the default PICH bit pattern of all zeros shall be 
transmitted. 

Data Frames sent on lub for different transport channels multiplexed on one secondary-CCPCH might indicate different 
transmission power levels to be used in a certain Uu frame. Node-B shall determine the highest DL power level 
required for any of the transport channels multiplexed in a certain Uu frame and use this power level as the desired 
output level for the data. 

In the case there is no data (i.e. no TB in the FP frame or no FP frame) in any transport channel for a given TTI and a 
TFCI is defined for no transmission on all transport channels multiplexed on the S-CCPCH, the TFCI transmit power is 
unspecified. 

Note: It can be for example or determined by the Node B relatively to Pret-nodata = Min (PCH Power, Max 

FACHl Power, Max FACH2 Power, ...., Max FACHn Powerj where PCH, FACHl, FACH2, ..., FACHn 
are the transport channels of the S-CCPCH [FDD , using the respective POl and P03 offsets specified in 
[10]]. 



5.1 .4 Downlink Shared Channels [TDD] 

The Data Transfer procedure is used to transfer a DSCH DATA FRAME from the CRNC to a Node B. 

If the Node B does not receive a valid DSCH DATA FRAME for transmission in a given TTI, it assumes that there is 
no data to be transmitted in that TTI for this transport channel. For the DSCH transport channel, the TFS shall never 
define a Transport Block Size of zero bits. 

The Node B shall use the header information in the DSCH DATA FRAME to determine which PDSCH Set [3.84Mcps 
and 7.68 Mcps TDD - and Transmit Power Level if no closed loop TPC power control is used] should be used in the 
PDSCH Uu frames associated to the specified CFN. The specified PDSCH Set [3.84Mcps and 7.68 Mcps TDD - and 
Transmit Power Level if no closed loop TPC power control is used] shall then be used for DSCH transmission for as 
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long as there is data to transmit or until a new DSCH DATA FRAME arrives that specifies that a different PDSCH Set 
[3.84Mcps and 7.68 Mcps TDD - and/or Transmit Power Level if no closed loop TPC power control is used] should be 
used. This feature enables multiple DSCH's with different TTI to be supported. 

The Node B may receive a DSCH data frame which contains a TFI value corresponding to there being no data to 
transmit, such a DSCH DATA FRAME will have no transport blocks. On receiving such a DATA FRAME the Node B 
shall apply the specified PDSCH Set [3.84Mcps and 7.68 Mcps TDD - and Transmit Power Level if no closed loop 
TPC power control is used] as described above starting in the PDSCH Uu frame associated to the specified CFN. This 
feature enables multiple DSCH's with different TTI to be supported, the use of such a zero payload DSCH DATA 
FRAME solves the problem of how the Node B should determine what PDSCH Set [3.84Mcps and 7.68 Mcps TDD - 
and Transmit Power Level if no closed loop TPC power control is used] should be used in the event that transmission of 
a transport block set being transmitted with a short TTI comes to an end, whilst the transmission of a TBS with a long 
TTI continues. 

Data Frames sent on lub for different DSCH transport channels multiplexed on one CCTrCH might indicate different 
transmission power levels to be used in a certain Uu frame. Node-B shall determine the highest DL power level 
required for any of the transport channels multiplexed in a certain Uu frame and use this power level as the desired 
output level. 



Node B 



CRNC 



DSCH DATA FRAME 



Figure 5: DSCH Data Transfer procedure 

5.1 .5 Uplink Shared Channels [TDD] 

Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC. Data Transfer 
procedure consists of a transmission of Data Frame from Node B to CRNC. 



Node B 



CRNC 



USCH DATA FRA^jlE 



Figure 6: USCH Data Transfer procedure 

Node B shall always send an USCH DATA FRAME to the CRNC provided the Transport Format addressed by the TFI 
indicates that the number of Transport Blocks is greater than 0. 

When UL synchronisation is lost or not yet achieved on the Uu, USCH DATA FRAMEs shall not be sent to the CRNC. 

When Node B receives an invaUd TFCI in the PUSCH, USCH DATA FRAMEs shall not be sent to the CRNC. 

5.1 .6 High Speed Downlink Shared Channels 

The Data Transfer procedure is used to transfer a HS-DSCH DATA FRAME (TYPE 1, TYPE 2 [FDD - or TYPE3]) 
from the CRNC to a Node B. HS-DSCH DATA FRAME TYPE 2 is selected if the IE HS-DSCH MAC-d PDU Size 
Format in NB AP [6] is present and set to "Flexible MAC-d PDU Size" [FDD - or if the IE HS-DSCH Common System 
Information is present and the UE is in Cell_FACH state. HS-DSCH DATA FRAME TYPE 3 is selected if the IE HS- 
DSCH Paging System Information in NBAP [6] is present and the UE is in Cell_PCH state or URA_PCH state]. HS- 
DSCH DATA FRAME TYPE 1 is selected in any other case. 
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[FDD - Three types of HS-DSCH Frame Protocols exist for HS-DSCH data transfer procedure, i.e., HS-DSCH Frame 
Protocol TYPE 1 (including HS-DSCH DATA FRAME TYPE 1 and HS-DSCH CAPACITY ALLOCATION TYPE I 
Control Frame), HS-DSCH Frame Protocol TYPE 2 (including HS-DSCH DATA FRAME TYPE 2 and HS-DSCH 
CAPACITY ALLOCATION TYPE 2 Control Frame) and HS-DSCH Frame Protocol TYPE 3 (including HS-DSCH 
DATA FRAME TYPE 3).] 

[TDD - Two types of HS-DSCH Frame Protocols exist for HS-DSCH data transfer procedure, i.e., HS-DSCH Frame 
Protocol TYPE 1 (including HS-DSCH DATA FRAME TYPE 1 and HS-DSCH CAPACITY ALLOCATION TYPE 1 
Control Frame) and HS-DSCH Frame Protocol TYPE 2 (including HS-DSCH DATA FRAME TYPE 2 and HS-DSCH 
CAPACITY ALLOCATION TYPE 2 Control Frame).] 

HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame shall be associated only with HS-DSCH DATA 
FRAME TYPE 1 while HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame shall be associated only with 
HS-DSCH DATA FRAME TYPE 2. HS-DSCH CAPACITY REQUEST Control Frame shall be used for both of HS- 
DSCH Frame Protocols. HS-DSCH Frame Protocol TYPE 2 is used for Flexible MAC-d PDU Size [FDD - and 
Enhanced Cell_FACH Operation] as described in NBAP [6]. 

When the CRNC has been granted capacity by the Node B via the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or 
TYPE 2) Control Frame or via the HS-DSCH initial capacity allocation as described in [6] and the CRNC has data 
waiting to be sent, then the HS-DSCH DATA FRAME (TYPE 1 or TYPE 2) is used to transfer the data. If the CRNC 
has been granted capacity by the Node B via the HS-DSCH initial capacity allocation as described in [6], this capacity 
is vaHd for only the first HS-DSCH DATA FRAME (TYPE 1 or TYPE 2) transmission. If the HS-DSCH Frame 
Protocol TYPE 2 has been selected by the Node B, the granted capacity shall be interpreted as the total number of octets 
which is retrieved by multiplying the maximum MAC-d PDU [FDD - or MAC-c PDU] length (indicated by the 
Maximum MAC-d/c PDU Length IE) with the number of MAC-d PDUs [FDD - or MAC-c PDUs] (indicated by the HS- 
DSCH Credits IE). When data is waiting to be transferred, and a CAPACITY ALLOCATION (TYPE 1 or TYPE 2) is 
received, a DATA FRAME (TYPE I or TYPE 2) will be transmitted immediately according to allocation received. 

In case of HS-DSCH Frame Protocol TYPE 1, multiple MAC-d PDUs of same length and same priority level (CmCH- 
PI) may be transmitted in one MAC-d flow in the same HS-DSCH DATA FRAME TYPE 1. 

In case of HS-DSCH Frame Protocol TYPE 2, MAC-d PDUs [FDD - or MAC-c PDUs] with the same logical channel 
ID shall be associated to one unique priority level (CmCH-PI). 

The HS-DSCH DATA FRAME (TYPE 1 and TYPE 2) includes a User Bujfer Size IE to indicate the amount of data 
pending for the respective MAC-d flow for the indicated priority level. [FDD - The HS-DSCH DATA FRAME TYPE 2 
includes PDUs for UE in Cell_FACH includes a User Bujfer Size IE to indicate the amount of data pending for the 
respective Common MAC flow for the indicated priority level.] Within one priority level (CmCH-PI) and size the 
MAC-d PDUs [FDD - or MAC-c PDUs] shall be transmitted by the Node B on the Uu interface in the same order as 
they were received from the CRNC. 

If the Flush IE in the HS-DSCH DATA FRAME (TYPE 1 and TYPE 2) is set to "flush" the Node B should remove all 
MAC-d PDUs [FDD - or MAC-c PDUs] from the corresponding MAC-hs Priority Queue that have been received prior 
to this data frame on the same transport bearer. 

For the purpose of TNL Congestion Control on HSDPA, the Frame Sequence Number and the DRT lEs may be 
included by the CRNC. 
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Figure 6A: HS-DSCH Data Transfer procedure 
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5.2 Node Synchronisation 



In the Node Synchronisation procedure, the RNC sends a DL NODE SYNCHRONISATION control frame to Node B 
containing the parameter Tl. Upon reception of a DL NODE SYNCHRONISATION control frame, the Node B shall 
respond with UL NODE SYNCHRONISATION control frame, indicating T2 and T3, as well as Tl which was 
indicated in the initiating DL NODE SYNCHRONISATION control frame. 

The Tl, T2, T3 parameters are defined as: 

T1:RNC specific frame number (REN) that indicates the time when RNC sends the frame through the SAP to the 
transport layer. 

T2:Node B specific frame number (BEN) that indicates the time when Node B receives the correspondent DL 
NODE SYNCHRONISATION control frame through the SAP from the transport layer. 

T3:Node B specific frame number (BEN) that indicates the time when Node B sends the frame through the SAP to 
the transport layer. 

The general overview on the Node Synchronisation procedure is reported in [2]. 

The procedure shall not be applied on transport bearers with IP multicast option. 



Node B 



CRNC 



DL NODE SYNCHRONISATION 



UL NODE SYNCHRONISATION 
► 



Figure 7: Node Synchronisation procedure 



5.3 DL Transport Channels Synchronisation 

CRNC sends a DL SYNCHRONISATION control frame to Node B. This message indicates the target CEN. 

Upon reception of the DL SYNCHRONISATION control frame Node B shall immediately respond with UL 
SYNCHRONISATION control frame indicating the ToA for the DL SYNCHRONISATION control frame and the 
CEN indicated in the received message. 

The procedure shall not be applied on transport bearers transporting UL traffic channels RACH or USCH. 

In case a CRNC sends DL SYNCHRONISATION control frame to Node B via IP multicast transport bearer, the target 
CEN indicates the target MEN. Upon reception of the DL SYNCHRONISATION control frame Node B shall 
immediately respond with UL SYNCHRONISATION control frame via one unicast transport bearer indicating the ToA 
for the DL SYNCHRONISATION control frame and the MEN indicated in the received message. 

In case a transport bearer without IP multicast option is used by several EACH channels, the procedure shall take place 
for all these EACH channels. 



Node B 



CRNC 



DL SYNCHRONISATION 



UL SYNCHRONISATION 

► 



Figure 8: Transport Chiannels Synchironisation procedure 
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5.4 DL Timing Adjustment 

Timing Adjustment procedure is used to indicate for the CRNC the incorrect arrival time of downlink data to Node B. 

Timing Adjustment procedure is initiated by the Node B if a DL frame arrives outside of the defined arrival window. 

If the DL frame has arrived before the ToAWS or after the ToAWE Node B includes the ToA and the target CFN as 
message parameters for TIMING ADJUSTMENT control frame. 

In case a transport bearer without IP multicast option is used by several EACH channels, the procedure shall take place 
for all these EACH channels. 

The arrival window and the time of arrival are defined as follows: 

- Time of Arrival Window Endpoint (ToAWE): ToAWE represents the time point by which the DL data shall 
arrive to the Node B from lub. The ToAWE is defined as the amount of milliseconds before the last time point 
from which a timely DL transmission for the identified CEN would still be possible taking into account the Node 
B internal delays. ToAWE is set via control plane. If data does not arrive before ToAWE a TIMING 
ADJUSTMENT control frame shall be sent by Node B. 

- Time of Arrival Window Startpoint (ToAWS): ToAWS represents the time after which the DL data shall 
arrive to the Node B from lub. The ToAWS is defined as the amount of milliseconds from the ToAWE. ToAWS 
is set via control plane. If data arrives before ToAWS a TIMING ADJUSTMENT control frame shall be sent by 
Node B. 

Time of Arrival (ToA): ToA is the time difference between the end point of the DL arrival window (ToAWE) 
and the actual arrival time of DL frame for a specific CFN. A positive ToA means that the frame is received 
before the ToAWE, a negative ToA means that the frame is received after the ToAWE. 

The general overview on the timing adjustment procedure is reported in [2]. 

Node B CRNC 



TIMING ADJUSTMENT 

► 



Figure 9: Timing Adjustment procedure 

5.5 Dynamic PUSCH Assignment [TDD] 

Procedure for dynamic allocation of physical resources to uplink shared channels (USCH) in the Node B. The control 
frame includes a parameter "PUSCH Set Id" which is a pointer to a pre-configured table of PUSCH Sets in the Node B. 

When this control frame is sent via a certain lub USCH data port, then it applies to that USCH and in addition to any 
other USCH channel which is multiplexed into the same CCTrCH in the Node B. 

The time limitation of the PUSCH allocation is expressed with the parameters "Activation CEN" and "Duration". 

Node B behaviour. When the Node B receives the "DYNAMIC PUSCH ASSIGNMENT" from the CRNC in the USCH 
frame protocol over an lub USCH data port within a Traffic Termination Point, it shall behave as follows: 

1) The Node B shall extract the PUSCH Set Id. 

2) It shall extract the parameters "Activation CEN" and "Duration" which identify the allocation period of that 
physical channel. 

3) It shall retrieve the PUSCH Set which is referred to by the PUSCH Set Id. 

4) It shall identify the CCTrCH to which the USCH is multiplexed, and hence the TFCS which is applicable for the 
USCH. 
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5) Within the time interval indicated by Activation CFN and Duration, the Node B shall make the specified PUSCH 
Set available to the CCTrCH. 



Node B 



CRNC 



DYNAMIC PUSCH 
ASSIGNMENT 



Figure 10: Dynamic PUSCIH Assignment procedure 

5.6 DSCH TFCI Signalling [FDD] 

Void. 

5.7 Timing Advance [3.84 IVIcps and 7.68l\/lcps TDD] 

This procedure is used in order to signal to the Node B the adjustment to be performed by the UE in the uplink timing. 

The Node B shall use the CFN and timing adjustment values to adjust its layer 1 to allow for accurate impulse 
averaging. 



Node B 



CRNC 



TIMING ADVANCE 



Figure 12: Timing Advance procedure 



5.7A Outer Loop PC Information Transfer [1 .28 Mcps TDD] 

Based, for example, on the CRCI values and on the quality estimate in the USCH data frames, CRNC modifies the SIR 
target of the associated CCTrCH by including the absolute value of the new SIR target in the OUTER LOOP PC control 
frame sent to the Node B. 

At the reception of the OUTER LOOP PC control frame from the CRNC via a Transport Bearer used for an USCH, the 
Node B shall immediately update the SIR target used for the inner loop power control for the respective CCTrCH with 
the specified value. 

The OUTER LOOP PC control frame can be sent via any of the transport bearers carrying USCHs which belong to the 
CCTrCH for which the UL SIR Target shall be adjusted. 
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NB 



CRNC 



^UTER LOOP PC 



Figure 12 A: Outer Loop Power Control Information Transfer procedure 



5.8 General 

5.8.1 Association between transport bearer and data/control frames 

Table 1 shows how the data and control frames are associated to the transport bearers, 'yes' indicates that the control 
frame is applicable to the transport bearer, 'no' indicates that the control frame is not applicable to the transport bearer. 

Table 1 



Transport 

bearer 

used for 


Associated 

data 

frame 


Associated control frames 


Timing 
Adjust- 
ment 


DL 
Transport 
Channels 
Synchroni- 
sation 


Node 

Synchroni 

sation 


Dynamic 
PUSCH 
Assign- 
ment 


Timing 
Advance 


Outer 

Loop 

PC Info 

Transfer 


HS-DSCH 
Capacity 
Request 


HS-DSCH 

Capacity 

Allocation 

TYPE1 


HS-DSC 

Capacit 

Allocatic 

TYPE 2 


RACH 


RACH 
DATA 
ERAME 


no 


no 


no 


no 


no 


no 


no 


no 


no 


EACH 


EACH 
DATA 
ERAME 


yes 


yes 


yes' 


no 


no 


no 


no 


no 


no 


PCH 


PCH DATA 
ERAME 


yes 


yes 


yes 


no 


no 


no 


no 


no 


no 


DSCH 


DSCH 
DATA 
ERAME 


yes 


yes 


yes 


no 


no 


no 


no 


no 


no 


USCH 


USCH 
DATA 
ERAME 
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no 
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no 


no 


no 
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yes 


no 


HS-DSCH 


HS-DSCH 
DATA 
ERAME 
TYPE 2 


no 


no 


yes 


no 


no 


no 
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no 


yes 


HS-DSCH 


HS-DSCH 
DATA 
ERAME 
TYPES 
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yes 
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no 


no 


no 


no 


no 


no 



NOTE: : The associated control frame is not applicable to the transport bearer with IP multicast option. 

5.8.2 DSCH / USCH transport bearer replacement [TDD] 

As described in NBAP [6], transport bearer replacement can be achieved fcir a DSCH or USCH by using the 
Synchronised Radio Link Reconfiguration Preparation procedure in combination with the Synchronised Radio Link 
Reconfiguration Commit procedure. The following steps can be discerned: 

1) The new transport bearer is established after which 2 transport bearers exist in parallel. 
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2) The transport channel(s) is/are switched to the new transport bearer. 

3) The old transport bearer is released. 

DSCH transport bearer replacement, step 1: 

Communication on the old transport bearer continues as normal. In addition, the Node B shall support DSCH DATA 
FRAMES, the DL Transport Channel Synchronisation procedure (see sub-clause 5.3) and the DL Timing Adjustment 
procedure (see sub-clause 5.4) on the new bearer. This enables the CRNC to determine the timing on the new transport 
bearer. DSCH DATA FRAMEs transported on the new transport bearer shall not be transmitted on the Uu Interface 
before the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message. 

USCH transport bearer replacement, step 1: 

Communication on the old transport bearer continues as normal. 
DSCH / USCH Transport Bearer Replacement step 2: 

Regarding step 2), the moment of switching is determined as follows: 

- The DSCH DATA FRAMEs or USCH DATA FRAMEs shall be transported on the new transport bearer from 
the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message. 

Starting from this CFN the Node B shall support all applicable Common Transport Channels frame protocol procedures 
on the new transport bearer and no requirements exist regarding support of Common Transport Channels frame protocol 
procedures on the old transport bearer. 

DSCH / USCH Transport Bearer Replacement step 3: 

Finally in step 3), the old transport bearer is released. 

5.8.3 HS-DSCH Transport Bearer Replacement 

As described in NBAP [6], transport bearer replacement can be achieved for a HS-DSCH MAC-d Flow by using the 
Synchronised Radio Link Reconfiguration Preparation procedure in combination with the Synchronised Radio Link 
Reconfiguration Commit procedure, or by using the Unsynchronised Radio Link Reconfiguration procedure. In both 
cases the following steps can be discerned: 

1) The new transport bearer is established after which 2 transport bearers exist in parallel. 

2) The HS-DSCH MAC-d Flow is switched to the new transport bearer. 

3) The old transport bearer is released. 

HS-DSCH Transport Bearer Replacement, step 1: 

Communication on the old transport bearer continues as normal. In addition, the Node B shall support HS-DSCH 
DATA FRAMES (TYPE 1 or TYPE 2), the HS-DSCH CAPACITY REQUEST Control Frame (see sub-clause 5.9) and 
may support the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame (see sub-clause 5.10) on 
the new transport bearer. HS-DSCH DATA FRAMEs (TYPE 1 or TYPE 2) transported on the new transport bearer 
shall be transmitted on the Uu Interface in the same way as those received on the old transport bearer (see sub-clause 
5.L6). 

The Node B may use the old or the new transport bearer for the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or 
TYPE 2) Control Frame. The HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame indicates 
the total amount of capacity granted for the MAC-d flow and the indicated priority level, irrespective of the transport 
bearer used. Any capacity previously granted is replaced. 

The RNC may use the old or the new transport bearer for the HS-DSCH CAPACITY REQUEST Control Frame. The 
rules for reissuing a HS-DSCH CAPACITY REQUEST Control Frame as outlined in sub-clause 5.9 still apply. 

HS-DSCH Transport Bearer Replacement, step 2: 

Regarding step 2), the moment of switching is determined as follows: 
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Starting from the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message - or directly when 
using the unsynchronised Radio Link Reconfiguration procedure, the Node B shall support all applicable Common 
Transport Channels frame protocol procedures on the new transport bearer and no requirements exist regarding support 
of Common Transport Channels frame protocol procedures on the old transport bearer. 

HS-DSCH Transport Bearer Replacement, step 3: 

Finally in step 3), the old transport bearer is released. 



5.9 HS-DSCH Capacity Request 
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Figure 12B: HS-DSCH Capacity Request procedure 

The HS-DSCH Capacity Request procedure provides means for the CRNC to request HS-DSCH capacity by indicating 
the user buffer size in the CRNC for a given priority level. 

The CRNC is allowed to reissue the HS-DSCH Capacity Request if no CAPACITY ALLOCATION (TYPE 1 or TYPE 
2) has been received within an appropriate time threshold. 



5.10 HS-DSCH Capacity Allocation 



NodeB 




CAPACITY ALLOCATION 



Figure 12C: HS-DSCH Capacity Allocation procedure 

HS-DSCH Capacity Allocation procedure is generated within the Node B. It may be generated either in response to a 
HS-DSCH Capacity Request or at any other time. 

The Node B may use this message to modify the capacity at any time, irrespective of the reported user buffer status. 

The HS-DSCH CAPACITY ALLOCATION (TYPE 1 and TYPE 2) Control Frame is used by the Node B to control the 
user data flow. In case of HS-DSCH Frame Protocol TYPE 1, the HS-DSCH Credits IE indicates the number of MAC-d 
PDUs that the CRNC is allowed to transmit for the MAC-d flow and the associated priority level indicated by the 
Common Transport Channel Priority Indicator IE. In case of HS-DSCH Frame Protocol TYPE 2, the HS-DSCH 
Credits IE indicates the number of MAC-d PDU [FDD - or MAC-c PDU] octets that the CRNC is allowed to transmit 
for the MAC-d flow [FDD - or Common MAC flow] and the associated priority level indicated by the Common 
Transport Channel Priority Indicator IE. The number of MAC-d PDU [FDD - or MAC-c PDU] octets is retrieved by 
multiplying the maximum MAC-d PDU [FDD - or MAC-c PDU] length (indicated by the Maximum MAC- d/c PDU 
Length IE) with the number of MAC-d PDUs [FDD - or MAC-c PDUs] (indicated by the HS-DSCH Credits IE). 
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The Maximum MAC-d PDU Length (in case of HS-DSCH Frame Protocol TYPE 1) or Maximum MAC- d/c PDU 
Length (in case of HS-DSCH Frame Protocol TYPE 2), HS-DSCH Credits, HS-DSCH Interval and HS-DSCH 
Repetition Period lEs indicates the total amount of capacity granted. Any capacity previously granted is replaced. 

If HS-DSCH Credits IE = (e.g. due to congestion in the Node B), the CRNC shall immediately stop transmission of 
MAC-d PDUs [FDD - or MAC-c PDUs]. If HS-DSCH Credits IE = 2047 in case of HS-DSCH CAPACITY 
ALLOCATION TYPE 1 Control Frame or 65535 in case of HS-DSCH CAPACITY ALLOCATION TYPE 2 Control 
Frame, the CRNC can transmit MAC-d PDUs [FDD - or MAC-c PDUs] with unlimited capacity. 

The lEs used in the HS-DSCH CAPACITY ALLOCATION Control Frame (TYPE 1 and TYPE 2) are the Common 
Transport Channel Priority Indicator, HS-DSCH Credits, Maximum MAC- d PDU Length (in case of HS-DSCH Frame 
Protocol TYPE 1) or Maximum MAC- d/c PDU Length (in case of HS-DSCH Frame Protocol TYPE 2), HS-DSCH 
Interval and the HS-DSCH Repetition Period. 

If the HS-DSCH Repetition Period IE = "unlimited repetition period" it indicates that the CRNC may transmit the 
amount of granted capacity for an unlimited period according to the bounds of Maximum MAC-d PDU Length IE 
(TYPE 1) or Maximum MAC- d/c PDU length IE (TYPE 2), HS-DSCH Credits IE and HS-DSCH Interval IE. 



Frame Structure and Coding 



6.1 



General 



The general structure of a Common Transport Channel frame consists of a header and a payload. This structure is 
depicted in figure 13. 



Header 


Payload: Data or Control Information 



Figure 13: General Frame Structure 

The header shall contain the Frame Type field and information related to the frame type. 
There are two types of frames (indicated by the Frame Type field). 

Data frame. 

Control frame. 
In the present document the structure of frames will be specified by using pictures similar to figure 14. 
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Spare Extension 



Byte 1 
Byte 2 
Byte 3 



Figure 14: Example frame structure 
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Unless otherwise indicated, fields which consist of multiple bits within a byte will have the more significant bit located 
at the higher bit position (indicated above frame in figure 14). In addition, if a field spans several bytes, more significant 
bits will be located in lower numbered bytes (right of frame in figure 14). 

On the lub interface, the frame will be transmitted starting from the lowest numbered byte. Within each byte, the bits 
are sent according decreasing bit position (bit position 7 first). 

The parameters are specified giving the value range and the step (if not 1). The coding is done as follows (unless 
otherwise specified): 

Unsigned values are binary coded. 

Signed values are 2's complement binary coded. 

The Spare Extension indicates the location where new lEs can in the future be added in a backward compatible way. 
The Spare Extension shall not be used by the transmitter and shall be ignored by the receiver. 

Bits labelled "Spare" shall be set to zero by the transmitter and shall be ignored by the receiver. 

6.2 Data frame structure 
6.2.1 RACH Channels 

The RACH DATA FRAME includes the CFN corresponding to the SEN of the frame in which the payload was 
received. If the payload was received in several frames, the CFN corresponding to the first Uu frame in which the 
information was received shall be indicated. 
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Figure 15: RACH DATA FRAME structure 

Propagation Delay is a conditional Information Element which is only present when the Cell supporting the RACH 
Transport Channel is a FDD Cell. 

Rx Timing Deviation is a conditional Information Element which is only present when the Cell supporting the RACH 
Transport Channel is a 3.84 Mcps or 7.68Mcps TDD Cell. 

Received SYNC UL Timing Deviation is a conditional Information Element which is only present when the Cell 
supporting the RACH Transport Channel is a 1.28Mcps TDD Cell. The RNC shall ignore this IE if the measured 
Received SYNC UL Timing Deviation is sent in Ext Received SYNC UL Timing Deviation IE 

With respect to new lEs, for which the presence is indicated by the New IE Flags IE, the Figure 15 is an example of 
how a frame is structured when all such new lEs are present. Note that non-presence of such a new IE changes the 
position of all subsequent lEs on octet level. 
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[FDD- Bit of New IE Flags in RACH DATA FRAME indicates if a Cell Portion ID is present (1) or not present (0) in 
the byte (bits 0-5) following the New IE Flags IE.] 

[FDD -Bit 1 of New IE Flags in RACH DATA FRAME indicates if Ext Propagation Delay IE in ^xtatnt {I) or not 
present (0)] 

[FDD - Bits 2 through 6 of New IE Flags in RACH DATA FRAME shall be set to 0.] 

[FDD - Field length of Spare Extension IE in RACH DATA FRAME is 0-28 octets.] 

[3.84 Mcps and 7.68 Mcps TDD - Bit of New IE Flags in RACH DATA FRAME indicates if the extended bits of the 
Rx Timing Deviation are present (1) or not present (0) in the byte (bit for 3.84 Mcps TDD, bits and 1 for 7.68 Mcps 
TDD) following the New IE Flags IE. Bits 1 through 6 of New IE Flags in RACH DATA FRAME shall be set to 0. 
Field length of Spare Extension IE in RACH DATA FRAME is 0-30 octets.] 

[1.28Mcps TDD - Bit of New IE Flags in RACH DATA FRAME indicates if the AOA IE is present (1) or not present 
(0).] 

[1.28Mcps TDD - Bit 1 of New IE Flags in RACH DATA FRAME indicates if Ext Received SYNC UL Timing 
Deviation IE is present (1) or not present (0)] 

[1.28Mcps TDD - Bits 2 through 6 of New IE Flags in RACH DATA FRAME shall be set to 0.] 

[1.28Mcps TDD - Field length of Spare Extension IE in RACH DATA FRAME is 0-27 octets.] 

6.2.2 CPCH Channels [FDD] 

Void. 



6.2.3 FACH Channels 

EACH DATA FRAME includes the CFN corresponding to the Uu frame at which this data in which the payload 
(FACH TBS) has to be transmitted. If the payload is to be sent in several frames, the CFN corresponding to the first 
frame shall be indicated. In case a transport bearer is used by several FACH channels, the CFN and Transmit power 
level are valid for all these FACH channels. 
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Figure 17: FACH DATA FRAME structure 

[1.28Mcps TDD - Bit of New IE Flags in FACH DATA FRAME indicates if the AOA IE is present (1) or not present 
(0).] 

6.2.4 PCH Channels 



The PCH DATA FRAME includes the paging indication information and paging messages [FDD - To page one User 
Equipment, two consecutive PCH DATA FRAMEs with consecutive CFN numbers are transmitted, the first frame 
contains the Paging Indication Information and the second contains the Paging Message.] [TDD - To page one User 
Equipment, one or more PCH DATA FRAMEs are trasmitted.] 

[TDD - If two or more consecutive frames are used, the first frame contains the Paging Indication Information and the 
rest contain the Paging Messages. If Pl-bitmap and PCH TBS ai-e both transmitted within the PCH DATA FRAME, the 
CFN is related to the PCH TBS only. The PI bitmap is mapped to the PICH frames, transmitted at the beginning of the 
paging block.] 

The paging messages are transmitted in S-CCPCH frames. The CFN in the PCH DATA FRAME header corresponds to 
the Cell SEN of the frame in which the start of the S-CCPCH frame is located. [TDD - If the paging messages are to be 
sent in several frames, the CFN corresponding to the first frame shall be indicated.] 



[FDD - The timing of the PICH frame (containing the paging indication information) is Xpich prior to the S-CCPCH 
frame timing [5]]. 

In contrast to all other Common Transport Channel data frames, which use a CFN of length 8, the PCH DATA FRAME 
includes a CFN of length 12. 



The Node B has no responsibility to ensure the consistency between the paging indication information and the 
corresponding paging messages. E.g. if the paging indication information is lost over the lub, the paging messages 
might be sent over the Uu while no UE is actually listening. 
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Figure 18: PCH DATA FRAME structure 

"Not Used" bits shall be set to by the RNC and ignored by the Node B. 

6.2.5 Downlink Shared Channels [TDD] 

DSCH DATA FRAME includes a CFN indicating the SFN of the PDSCH in which the payload shall be sent. If the 
payload is to be sent over several frames, the CFN corresponding to the first frame shall be indicated. 
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Figure 20: DSCH DATA FRAME structure 



6.2.6 Uplink Shared Channels [TDD] 

USCH DATA FRAME includes the CFN in which the payload was received. If the payload was received in several 
frames, the CFN corresponding to the first frame will be indicated. 
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Figure 21 : USCH DATA FRAME structure 

[3.84 Mcps and 7.68 Mcps TDD - Field length of Spare Extension IE in USCH DATA FRAME is 0-30 octets. 

Bit of New IE Flags in USCH DATA FRAME indicates if the extended bits of the Rx Timing Deviation are present 
(1) or not present (0) in the byte (bit for 3.84 Mcps TDD, bits and 1 for 7.68 Mcps TDD) following the New IE 
Flags IE. Bits 1 thi'ough 6 of New IE Flags in USCH DATA FRAME shall be set to 0.] 

6.2.6A HS-DSCH Channels 

[FDD - Three types of HS-DSCH DATA FRAME exist for the HS-DSCH data transfer, i.e. HS-DSCH DATA FRAME 
TYPE 1, HS-DSCH DATA FRAME TYPE 2 and HS-DSCH DATA FRAME TYPE 3.] 

[TDD - Two types of HS-DSCH DATA FRAME exist for the HS-DSCH data transfer, i.e. HS-DSCH DATA FRAME 
TYPE 1 and HS-DSCH DATA FRAME TYPE 2.] 



ETSI 



3GPP TS 25.435 version 7.10.0 Release 7 



28 



ETSI TS 125 435 V7.10.0 (2009-01) 



Header CRC 


FT 






Frame Seq Nr 


CmCH-PI 




MAC-d PDU Length 




MAC-d PDU Length (cont) 


Flush 


FSN/ 
DRT 
Reset 


Spare 



> Header 


Num Of PDUs 




User Buffer Size 




User Buffer Size (cont) 








Spare, bits 7-4 


MAC-d PDU 1 


J 









IVIAC-d PDU 1 (cont) 


Pad 




• 
o 




Spare, bits 7-4 


MAC-d PDU n 




O o 


\Payload 


IVIAC-d PDU n (cont) 


Pad 


New IE Flags 

7(E) 6 5 4 3 2 10 




DRT 




DRT (cont) 




Spare Extension 




Pay load CRC 




Payload CRC (cont) 





Figure 21 A: HS-DSCH DATA FRAME TYPE 1 structure 

Bit of New IE Flags in HS-DSCH DATA FRAME TYPE 1 indicates if a DRT is present (1) or not (0) in the 2 octets 
following the f^ew IE Flags IE. Bits 1 through 6 of New IE Flags in HS-DSCH DATA FRAME TYPE 1 shall be set to 
0. 

Field length of Spare Extension IE in HS-DSCH DATA FRAME TYPE 1 is 0-29 octets. 



ETSI 



3GPP TS 25.435 version 7.10.0 Release 7 



29 



ETSI TS 125 435 V7.10.0 (2009-01) 



r 



First block 
of PDUs 
with the 

same size 



< 



V 



nth blocl< of 

PDUs with 

the same 

size 



7 















Header CRC 


FT 


Frame Seq Nr 


CmCH-PI 


Total Num of PDU blocks 


Fiusii 


™.T 


DRT 

IlldiL-LlUl. 


hi 


Spare 6-0 


User Buffer Size 


User Buffer Size (cont) 


IVIAC-d/c PDU length in block 1 


M ten 1 (cont) 


spare 


#PDUs in block 1 


Logical Ch ID in block 1 


MAC-d/c PDU length in block 2 


M ten 2 (cont) 


spare 


#PDUs in block 2 


Logicai Ch ID in block 2 







MAC-d/c PDU length in block n 


M len n (cont) 


spare 


#PDUs in block n 


Logical Ch ID in block n 


Padding if n is odd 



DRT 



DRT (cont) 



H-RNTI 



H-RNTI (cont) 



RACH Measurement Result 



MAC-d/c PDU 1 



coo 



MAC-d/c PDU 1 (cont) 



MAC-d/c PDU m1 



MAC-d/c PDU m1 (cont) 



MAC-d/c PDU 1 



MAC-d/c PDU mn (cont) 



Spare Extension 



Payload CRC 



Payload CRC (cont) 



A 



Header 



J 
\ 



\Payload 

I 



J 



Figure 21 B: HS-DSCH DATA FRAIVIE TYPE 2 structure 

[FDD - If the received H-RNTI IE sets to same value as the BCCH Specific HS-DSCH RNTI IE configured in NBAP[6], 
the Node B shall ignore RACH Measurement Result IE in the frame.] 
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Figure 21 C: HS-DSCH DATA FRAME TYPE 3 structure [FDD only] 

[FDD - The CFN in the HS-DSCH DATA FRAME TYPE 3 header coiTesponds to the Cell SEN of the frame in which 
the start of the HS-SCCH frame is located. The timing of the PICH frame (containing the paging indication 

information) is Tpich prior to the HS-SCCH frame timing [5]]. 

[FDD - Note: The HS-SCCH frame is not sent if/// IE is set to 0, i.e. H-RNTI not present.] 
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6.2.7 Coding of information elements in data frames 

6.2.7.1 Header CRC 

Description: Cyclic Redundancy Checksum calculated on the header of a data frame with polynom: 

The CRC calculation shall cover all bits in the header, starting from bit in the first byte (FT field) up to the end of the 
header. See subclause 7.1. 

Value range: {0..127}. 

Field length: 7 bits. 

6.2.7.2 Frame Type 

Description: Describes if it is a control frame or a data frame. 
Value range: {0=data, l=control}. 
Field Length: 1 bit. 

6.2.7.3 Connection Frame Number (CFN) 

Description: Indicator as to which radio frame the first data was received on uplink or shall be transmitted on 
downlink. In case a transport bearer is used by several FACH channels with IP multicast option, the radio frame in 
which the first data shall be transmitted on a FACH mapping on the transport bearer shall be calculated according to: 

CFN = (MFN - CFN Offset) mod 256, 

where: 

MFN is the value of CFN field in the data frame; 

- CFN Offset is a FACH parameter indicated by RNC [6]. 

The value range and field length depend on the transport channel for which the CFN is used. 

Value range (PCH): {0..4095}. 

Value range (other): {0.255}. 

Field length (PCH): 12 bits. 

Field length (other): 8 bits. 

6.2.7.4 Transport Format Indicator 

Description: TFI is the local number of the transport format used for the transmission time interval. For information 
about what the transport format includes see [3]. 

Value range: {0..31}. 

Field length: 5 bits. 

6.2.7.5 Propagation Delay [FDD] 

Description: One-way radio interface delay as measured during RACH access. If the measured value exceeds the range 
of this information element, the information element shall be set to its maximum value, and the Ext Propagation Delay 
IE shall be used to represent the measured value, see subclause 6.2. 7. 5A. 

Value range: {0..765 chips}. 

Granularity: 3 chips. 
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Field length: 8 bits. 

6.2.7.5A Ext Propagation Delay [FDD] 

Description: One-way radio interface delay as measured during RACH access, extended value part. This IE shall be 
present only if the range of the Propagation Delay IE is insufficient to represent the measured value. 

Value range: {0 - 3069 chips}. 

Granularity: 3 chips. 

Field length: 10 bits. 

6.2.7.6 Rx Timing Deviation [3.84Mcps TDD] 

Description: Measured Rx Timing Deviation as a basis for timing advance. This value should consider measurements 
made in all frames and all timeslots that contain the transport blocks in the payload. In case the Timing Advance Applied 
IE indicates "No" (see [6]) in a cell, the Rx Timing Deviation field shall be set to N = 0. 

Value range: {-1024 .. +1023 chips}. 

{N*4 -256} chips < RxTiming Deviation < {(N+l)*4 - 256} chips. 

WithN = 0, 1,.., 127. 

{(N-128)*4 - 1024} chips < Rx Timing Deviation < {(N-127)*4 - 1024} chips 

WithN= 128, 129, ...,319 

{N*4 - 1024} chips < Rx Timing Deviation < {(N+l)*4 - 1024} chips 

With N = 320, 321, ...,511 

Granularity: 4 chips. 

Field length: 9 bits. The least significant 8 bits are contained in the RX timing deviation field and the most significant 
bit is contained in the RX timing deviation (continuation) field. 

6.2.7.6A Received SYNC UL Timing Deviation [1 .28Mcps TDD] 

Description: Measured Received SYNC UL Timing Deviation as a basis for propagation delay. 
Value range: {0, .., +255} chips 
Granularity: 1 chip. 
Field length: 8 bits. 

6.2.7.6B Rx Timing Deviation [7.68Mcps TDD] 

Description: Measured Rx Timing Deviation as a basis for timing advance. This value should consider measurements 
made in all frames and all timeslots that contain the transport blocks in the payload. In case the Timing Advance Applied 
IE indicates "No" (see [6]) in a cell, the Rx Timing Deviation field shall be set to N = 0. 

Value range: {-2056, ..., +2055} chips 

{N*4 -2056} chips < RxTiming Deviation < {(N+l)*4 -2056} chips 

WithN = 0, 1,..., 1027 

Granularity: 4 chips. 

Field length: 10 bits. The least significant 8 bits are contained in the RX timing deviation field and the most significant 
2 bits are contained in the RX timing deviation (continuation) field. 
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6.2.7.7 Transport Block 

Description: A block of data to be transmitted or have been received over the radio interface. The transport format 
indicated by the TFI describes the transport block length and transport block set size. See [3]. 

6.2.7.8 CRC Indicator 

Description: Shows if the transport block has a correct CRC. The UL Outer Loop Power Control may use the CRC 
indication. 

Value range: {0=Correct, l=Not Correct}. 

Field length: 1 bit. 

6.2.7.9 Payload CRC 

Description: Cyclic Redundancy Checksum calculated on the payload of a data frame with polynom 

X'\16+X'^15+X'^2+l. 

The CRC calculation shall cover all bits in the data frame payload, starting from bit 7 in the first byte up to bit in the 
byte before the payload CRC. See subclause 7.1. 

Field length: 16 bits. 

6.2.7.10 Transmit Power Level 

Description: Preferred transmission power level during this TTl for the corresponding transport channel. The indicated 
value is the negative offset relative to the maximum power configured for the physical channel(s) used for the 
respective transport channel. [1.28Mcps TDD - The Node B shall ignore the Transmit Power Level in the TDD DSCH 
DATA FRAME.] [3.84Mcps and 7.68Mcps TDD - The Node B shall ignore the Transmit Power Level in the TDD 
DSCH DATA FRAME if closed loop TPC power control is used.] 

Value range: {0.. 25.5dB}. 

Granularity: 0,1 dB. 

Field length: 8 bits. 

6.2.7.11 Paging Indication (PI) 

Description: Describes if the PI Bitmap is present in the payload. 
Value range: {0=no Pl-bitmap in payload, l=PI-bitmap in payload}. 
Field length: 1 bit. 

6.2.7.12 Paging Indication bitmap (Pl-bitmap) 

Description: Bitmap of Paging Indications PIo..PIn-i- Bit 7 of the first byte contains PIO, Bit6 of the first byte contains 
PI1„. . ., Bit7 of the second byte contains PI8 and so on. 

Value range: [FDD- {18, 36, 72 or 144 Paging Indications}.] 

[3.84Mcps TDD - {30, 34, 60, 68, 120 and 136} Paging Indications for 2 PICH frames, 

{60, 68, 120, 136, 240 and 272} Paging Indications for 4 PICH frames]. 

[1.28Mcps TDD - {44, 88 and 176} Paging Indications for 2 PICH frames, 
{88, 176 and 352} Paging Indications for 4 PICH frames]. 

[7.68Mcps TDD - {30, 34, 60, 68, 120 and 136} Paging Indications for 2 PICH frames, 

{60, 68, 120, 136, 240 and 272} Paging Indications for 4 PICH frames, 
{ 120, 1 36, 240, 272, 480 and 544 } Paging Indications for 8 PICH frames] . 
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Field length: [FDD - 3, 5, 9 or 18 bytes (the Pl-bitmap field is padded at the end up to an octet boundary)]. 

[3.84Mcps TDD - 4, 5, 8, 9, 15, 17, 30 or 34 bytes (the Pl-bitmap field is padded at the endup to an 
octet boundary)]. 

[1.28Mcps TDD - 6, 1 1, 22 or 44 bytes (the Pl-bitmap field is padded at the endup to an octet 
boundary)]. 

[7.68Mcps TDD - 4, 5, 8, 9, 15, 17, 30, 34, 60 or 68 bytes (the Pl-bitmap field is padded at the end up 
to an octet boundary)]. 

6.2.7.1 3 Rx Timing Deviation on RACH [3.84Mcps TDD] 

Void. 

6.2.7.14 PDSCH Set Id [TDD] 

Description: A pointer to the PDSCH Set which shall be used to transmit the DSCH DATA FRAME over the radio 
interface. 

Value range: {0..255}. 

Field length: 8 bits. 

6.2.7.1 5 Code Number [FDD] 

Void. 



6.2.7.16 Spreading Factor (SF) [FDD] 

Void. 

6.2.7.17 Power Offset [FDD] 

Void. 

6.2.7.18 MClnfo [FDD] 
Void. 

6.2.7.19 Spare Extension 

Description: Indicates the location where new IBs can in the fiiture be added in a backward compatible way. 
Field length: 0-32 octets. 

6.2.7.20 Quality Estimate (QE) [TDD] 

Description: The quality estimate is derived from the Transport channel BER. 

If the USCH FP frame includes TB's for the USCH then the QE is the Transport channel BER for the selected USCH. If 
no Transport channel BER is available the QE shall be set to 0. 
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The quality estimate shall be set to the Transport channel BER and be measured in the units TrCH_BER_LOG 
respectively (see [6]). The UL Outer Loop Power Control may use the quality estimate. 

Value range: {0..255}. 

Granularity: 1. 

Field length: 8 bits. 

6.2.7.21 Common Transport Channel Priority Indicator (CmCH-PI) 

Description: CmCH-PI, configured via the Scheduling Priority Indicator in NEAP [6], is the relative priority of the 
data frame and the SDUs included. 

Value range: {0-15, where 0=lo west priority, 15=highest priority}. 

Field length: 4 bits. 

6.2.7.22 User Buffer Size 

Description: Indicates the users' buffer size (i.e. the amount of data in the buffer) in octets for a given Common 
Transport Channel Priority Indicator level. 

Value range: {0-65535}. 

Field length: 16 bits. 

6.2.7.23 MAC-d PDU Length 

Description: The value of that field indicates the length of every MAC-d PDU in the payload of the HS-DSCH DATA 
FRAME in number of bits. 

Value range: {0-5000}. 
Field Length: 13 bits. 

6.2.7.24 NumOfPDU 

Description: Indicates the number of MAC-d PDUs in the payload. 
Value range: { 1-255}. 
Field Length: 8 bits. 

6.2.7.25 MAC-d PDU 

Description: A MAC-d PDU contains the MAC-d PDU as defined in [9]. 
Field length: See the value of the MAC-d PDU Length IE. 

6.2.7.26 Cell Portion ID [FDD] 

Description: Cell Portion ID indicates the cell portion with highest SIR during RACH access. Cell Portion ID is 
configured by O&M. 

Value range: {0-63}. 
Field Length: 6 bits. 

6.2.7.27 New IE Flags 

Description: The New IE Flags IE is only present if at least one new IE is present. The New IE Flags IE contains flags 
indicating which new lEs that are present following the New IE Flags IE. The last bit position of the New IE Flags IE is 
used as the Extension Flag to allow the extension of the New IE Flags IE in the future. Extension octets of the New IE 
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Flags IE shall follow directly after the first octet of the New IE Flags IE. When an extension octet of the New IE Flags 
IE is present, then all previous extension octets of the New IE Flags IE and the New IE Flags IE shall also be present, 
even if they have all their flag bits indicating no presence of their respective new lEs. 

Value range: 

Bit 0-6 of each octet: Indicates if a new IE is present ( 1 ) or not present (0) in the bytes following the New IE Flags IE. 
The meaning of each bit is explained in the corresponding DATA FRAME subclause; 

Bit 7 of each octet: Indicates if an extension octet of the New IE Flags IE follows (1) or not (0). 

Field length: 1-31 octets. 

6.2.7.28 Flush 

Description: Indicates whether the DRNS should remove (1) or not (0) all the MAC-d PDUs from the corresponding 
MAC-hs Priority Queue that have been received prior to this data frame HS-DSCH DATA FRAME on the same 
transport bearer. 

Value range: {0 = no flush, 1 = flush}. 

Field Length: 1 bit. 

6.2.7.29 DRT (Delay Reference Time) 

Description: DRT is a 16-bit Delay Reference Time. DRT can be used for dynamic delay measurements. The DRT 
counter bridges the same time span as RFN and BFN. DRT is locked to RFN in SRNC and is a 40960 counter with 1 ms 
resolution. 

Value range: {0..40959dec ms (0..9FFFhex ms)}. 

Granularity: 1 ms. 

Field length: 16 bits. 

6.2.7.30 Frame Sequence Number 

Description: The 4-bit Frame Sequence Number is incremented for each transmitted HS-DSCH data frame belonging 
to one MAC-d flow. At wraparound of the Frame Sequence Number, the value "0" shall not be used. Each flow 
generates its own Frame Sequence. 



Value range: 



is a special value and indicates that the Frame Sequence Number IE shall be treated as 

spare. 



1-15 indicates the Frame Sequence Number. 
Granularity: 1. 
Field length: 4 bits. 

6.2.7.31 Logical Channel ID in block n 

Description: This field provides identification of the logical channel instance associated with the PDUs of the n-th 
block of PDUs with the same size in the HS-DSCH DATA FRAME TYPE 2 [FDD - and TYPE 3]. Multiple logical 
channels may be carried on the same MAC-d flow [FDD - , Common MAC flow or Paging MAC flow]. 

Value range: {0-15}, where 0-14 identifies logical channels 1-15, 15 reserved. 

Field length: 4 bits. 
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6.2.7.32 Total Number of PDU blocks 

Description: The field indicates the number of blocks of block ofPDUs with the same size in this HS-DSCH DATA 
FRAME. 

Value range: {0-31 }, - not used. 

Field length: 5 bits. 

6.2.7.33 MAC-d/c PDU Length in block n 

Description: The value of this field indicates the length of every MAC-d PDU [FDD - or MAC-c PDU] in the n-th 
block ofPDUs with the same size in number of octets. 

Value range: {0-1504}, - not used. 

Field length: 1 1 bits. 

6.2.7.34 Number of MAC-d/c PDUs In block n (#PDUs in block n) 

Description: Indicates the number of MAC-d PDUs [FDD - or MAC-c PDUs] in the n-th block ofPDUs with the same 
size. 

Value range: {0-15}, - not used. 

Field length: 4 bits. 

6.2.7.35 DRT Indicator 

Description: Indicates whether a DRT is present. 
Value range: {0 = DRT not present, 1= DRT present}. 
Field length: 1 bit. 

6.2.7.36 FACH Indicator (Fl) [FDD] 

Description: Indicates whether an H-RNTI and a RACH Measurement Result are present (i.e. whether UE in 
CELL_FACH). 

Value range: {0 = H-RNTI and RACH Measurement Result not present, 1= H-RNTI and RACH Measurement Result 
present}. 

Field length: 1 bit. 

6.2.7.37 H-RNTI [FDD] 

Description: H-RNTI is defined in [1 1]. The field identifies an UE having a HS-PDSCH assignment within a cell. 
Value range: {0-65535}, - not used. 
Field length: 16 bits. 

6.2.7.38 RACH Measurement Result [FDD] 

Description: This filed indicates the values received in RACH Measurement. The type of the measured value in the 
field is configured via NBAP [6]. 

Value range: {0-158} 

Field length: 8 bits. 
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6.2.7.39 H-RNTI Indicator (HI) [FDD] 

Description: Indicates whether an H-RNTI and a CmCH-PI are present. 

Value range: {0 = H-RNTI and CmCH-PI not present, 1= H-RNTI and CmCH-PI present}. 

Field length: 1 bit. 

6.2.7.40 FSN/DRT Reset 

Description: When the Node B receives a HS-DSCH DATA FRAME where the 1-bit FSN/DRT Reset IE is set to 1, the 
Node B should reset any state of congestion estimation based on previously received FSN and DRT values. Node B 
may instead decide to start a new estimation of congestion detection initiated with the FSN and DRT values included in 
this HS-DSCH data frame. FSN/DRT Reset IE set to 1 may indicate a discontinuity in the sequence of the transmitted 
DRT and FSN values in the transmitted HS-DSCH data frames belonging to the associated MAC-d flow. 

If the 1-bit FSN/DRT Reset IE is set to 0, Node B may use the included DRT and FSN values for congestion detection. 

Value range: 

Node B may use the included DRT and FSN values for congestion detection. 

1 Node B should not use previously received FSN and DRT values for congestion detection. 
Field length: 1 bit. 

6.2.7.41 MAC-d/c PDU 

Description: A MAC-d/c PDU contains the MAC-ehs SDU as defined in [9]. 

Field length: For length of MAC-d/c PDU of block n, see the value of the MAC-d/c PDU length in block n IE. 

6.2.7.42 AOA (Angle of Arrival) [1 .28Mcps TDD] 

Description: This filed indicates the angle of arrival information of UE measured by Node B. 
Value range: {0-719} 
Field length: 10 bit. 

6.2.7.43 Ext Received SYNC UL Timing Deviation [1 .28Mcps TDD] 

Description: Measured Received SYNC UL Timing Deviation as a basis for propagation delay. 
Value range: {0, .., h-1023} chips 
Granularity: 1/8 chip. 
Field length: 13 bits. 

6.3 Control frame structure 
6.3.1 Introduction 

The Common Control Channel control frames are used to transport control information between the CRNC and the 
Node B. Figure 22 defines the Control Frame structure for common transport channels. 
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Frame CRC 



Control Frame Type 



Control information 



Control information (cont.) 



FT 



Header (2 bytes) 



V_ Payload (variable length) 



Figure 22: lub Common Transport Channel Control Frame Format 

The structure of the header and the payload of the control frames is defined in the following subclauses. 

6.3.2 Coding of information elements of tine Control frame header 



6.3.2.1 



Frame CRC 



Description: Cyclic Redundancy Checksum calculated on a control frame with polynom: 

The CRC calculation shall cover all bits in the control frame, starting from bit in the first byte (FT field) up to the end 
of the control frame. See subclause 7.1. 

Value range: {0..127}. 

Field length: 7 bits. 

6.3.2.2 Frame Type (FT) 

Refer to subclause 6.2.7.2. 

6.3.2.3 Control Frame Type 

Description: Indicates the type of the control information (information elements and length) contained in the payload. 
Value: Values of the Control Frame Type parameter are defined in table 2. 

Table 2 



Type of control frame 


Value 


OUTER LOOP POWER CONTROL 


0000 0001 


TIMING ADJUSTMENT 


0000 0010 


DL SYNCHRONISATION 


0000 001 1 


UL SYNCHRONISATION 


0000 0100 


Reserved Value 


0000 0101 


DL NODE SYNCHRONISATION 


0000 0110 


UL NODE SYNCHRONISATION 


0000 0111 


DYNAMIC PUSCH ASSIGNMENT 


0000 1000 


TIMING ADVANCE 


0000 1001 


HS-DSCH Capacity Request 


0000 1010 


HS-DSCH Capacity Allocation TYPE 1 


0000 1011 


HS-DSCH Capacity Allocation TYPE 2 


0000 1100 



Field Length: 8 bits. 
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The "Reserved Value" for the Control Frame Type IE shall not be used by the SRNC. A control frame whose Control 
Frame Type IE is set to the "Reserved Value" shall be ignored by the Node B. 

6.3.3 Payload structure and information elements 

6.3.3.1 TIMING ADJUSTMENT 

6.3.3.1.1 Payload Structure 

Figures 23 and 24 shows the structure of the payload when control frame is used for the timing adjustment. 



CFN 



ToA 



ToA (cont) 



Spare Extension 



Number of 

bytes 



V Payload 



0-32 



J 



Figure 23: TIMING ADJUSTMENT payload structure (non-PCH transport bearers) 

Number of 
bytes 



CFN 


CFN(cont) 


Not Used 


ToA 


ToA (cont) 


ToA(cont) 


Not Used 


Spare Extension 



0-32 



Payload 



Figure 24: TIMING ADJUSTMENT payload structure (PCH transport bearer) 



6.3.3.1.2 CFN 

Refer to subclause 6.2.7.3. 
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6.3.3.1.3 



Time of arrival (ToA) 



Description: Time difference between the arrival of the DL frame with respect to TO AWE (based on the CFN in the 
frame). The value range and field length depend on the transport channel for which the CFN is used. 

Value range (PCH): {-20480ms, +20479.875ms}. 

Value range (other): {-1280ms, H-1279.875ms}. 

Granularity: 125)is. 

Field length (PCH): 20 bits. 

Field length (other): 16 bits. 

6.3.3.1.4 Spare Extension 

Description: Indicates the location where new IBs can in the future be added in a backward compatible way. 
Field length: 0-32 octets. 



6.3.3.2 



DL SYNCHRONISATION 



6.3.3.2.1 Payload Structure 

Figures 25 and 26 shows the structure of the payload when control frame is used for the user plane synchronisation. 



Number of 
bytes 



CFN 



Spare Extension 



^ Payload 



0-32 



Figure 25: DL SYNCHRONISATION payload structure (non-PCH transport bearers) 

Number of 
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CFN 


CFN(cont) 


Not Used 


Spare Extension 



1 
1 

0-32 



>■ Payload 



Figure 26: DL SYNCHRONISATION payload structure (PCH transport bearers) 
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6.3.3.2.2 CFN 
Refer to subclause 6.2.7.3. 

6.3.3.2.3 Spare Extension 

Refer to subclause 6.3.3.1.4. 

6.3.3.3 UL SYNCHRONISATION 

6.3.3.3.1 Payload Structure 



Figures 27 and 28 shows the structure of the payload when the control frame is used for the user plane synchronisation 
(UL). 



Number of 
bytes 



CFN 



ToA 



ToA (cont) 



Spare Extension 



~\ 



V Payload 



0-32 
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Figure 27: UL SYNCHRONISATION payload structure (non-PCH transport bearers) 
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CFN(cont) 


Not Used 


ToA 


ToA (cont) 


ToA(cont) 


Not Used 


Spare Extension 



Payload 



0-32 



Figure 28: UL SYNCHRONISATION payload structure (PCH transport bearers) 



6.3.3.3.2 CFN 

Refer to subclause 6.2.7.3. 
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6.3.3.3.3 Time of Arrival (TOA) 

Refer to subclause 6.3.3.1.3. 

6.3.3.3.4 Spare Extension 

Refer to subclause 6.3.3.1.4. 



6.3.3.4 



DL NODE SYNCHRONISATION 



6.3.3.4.1 Payload Structure 

The payload of the DL Node synchronisation control frames is shown in figure 29. 



Tl 



Tl (cont) 



Tl (cont) 



Spare Extension 



Number of 

bytes 



1 
1 

0-32 



> 



Payload 



Figure 29: DL NODE SYNCHRONISATION payload structure 



6.3.3.4.2 



T1 



Description: RNC specific frame number (RFN) that indicates the time when RNC sends the frame through the SAP to 
the transport layer. 

Value range: {0 .. 40959.875 ms}. 

Granularity: 0.125ms. 

Field length: 24 bits. 

6.3.3.4.3 Spare Extension 

Refer to subclause 6.3.3.1.4. 



6.3.3.5 



UL NODE SYNCHRONISATION 



6.3.3.5.1 Payload Structure 

The payload of the UL Node synchronisation control frames is shown in figure 30. 
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Number of 
bytes 



7 







Tl 


Tl (cont) 


Tl (cont) 


T2 


T2 (cont) 


T2 (cont) 


T3 


T3 (cont) 


T3 (cont) 


Spare Extension 



0-32 



Pay load 



Figure 30: UL NODE SYNCHRONISATION payload structure 

6.3.3.5.2 T1 

Description: Tl timer is extracted from the correspondent DL Node synchronisation control frame. 

Value range: {0 .. 40959.875 ms.} 

Granularity: 0.125ms. 

Field length: 24 bits. 



6.3.3.5.3 



T2 



Description: Node B specific frame number (BFN) that indicates the time when Node B received the correspondent DL 
synchronisation frame through the SAP from the transport layer. 

Value range: {0 .. 40959.875 ms}. 

Granularity: 0.125ms. 

Field length: 24 bits. 



6.3.3.5.4 



T3 



Description: Node B specific frame number (BFN) that indicates the time when Node B sends the frame through the 
SAP to the transport layer. 

Value range: {0 .. 40959.875 ms}. 

Granularity: 0.125ms. 
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Field length: 24 bits. 

6.3.3.5.5 Spare Extension 

Refer to subclause 6.3.3.1.4. 



6.3.3.6 



DYNAMIC PUSCH ASSIGNMENT [TDD] 



6.3.3.6.1 Payload structure 

The payload of the Dynamic PUSCH Assignment control frames is shown in figure 3 1 . 
7 



PUSCH Set Id 



Activation CFN 



Duration 



> Payload (3 bytes) 



6.3.3.6.2 



Figure 31 : DYNAMIC PUSCH ASSIGNMENT payload structure 



PUSCH Set Id 



Description: Identifies a PUSCH Set from the collection of PUSCH Sets which have been pre-configured in the 
Node B, for the respective cell in which the USCH exists. The PUSCH Set Id is unique within a cell. 

Value range: {0..255}. 

Field length: 8 bits. 



6.3.3.6.3 



Activation CFN 



Description: Activation CFN, specifies the Connection Frame Number where the allocation period of that PUSCH Set 

starts. 

Value range: Integer {0..255}. 
Field length: 8 bits. 

6.3.3.6.4 Duration 

Description: Indicates the duration of the activation period of the PUSCH Set, in radio frames. 
Value range: 0..255 means: to 255 radio frames, i.e. to 2550 msec. 
Field length: 8 bits. 

6.3.3.7 DSCH TFCI SIGNALLING [FDD] 



6.3.3.7.1 
Void. 



Payload structure 



6.3.3.7.2 
Void. 



TFCI (field 2) 
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6.3.3.7.3 
Void. 



Spare Extension 



6.3.3.8 TIMING ADVANCE [3.84Mcps and 7.68Mcps TDD] 

6.3.3.8.1 Payload structure 

Figure 33 shows the structure of the payload when the control frame is used for timing advance. 

Number of 
Octets 



7 







CFN 


Spare 


TA 


Spare Extension 



1 
1 

0-32 
Figure 33: TIMING ADVANCE payload structure 



"N 



> Payload 



y 



6.3.3.8.2 CFN 
Refer to subclause 6.2.7.3. 

6.3.3.8.3 TA [3.84 Mcps] 
Description: UE applied UL timing advance adjustment. 
Value range: {0 .. 252 chips}. 

Granularity: 4 chips. 
Field length: 6 bits. 

6.3.3.8.3A TA [7.68 Mcps] 

Description: UE applied UL timing advance adjustment. 
Value range: {0 .. 508 chips}. 
Granularity: 4 chips. 
Field length: 7 bits. 

6.3.3.8.4 Spare Extension 

Refer to subclause 6.3.3.1.4. 



6.3.3.9 



OUTER LOOP POWER CONTROL [1 .28 Mcps TDD] 



6.3.3.9.1 Payload structure 

Figure 34 shows the structure of the payload when control frame is used for the UL outer loop power control. 
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Number of 
Octets 



UL SIR TARGET 



Spare Extension 



1 

0-32 



> Payload 



Figure 34: Structure of the payload for OUTER LOOP PC control frame 

6.3.3.9.2 SIR Target 

Description: Value (in dB) of the SIR target to be used by the UL inner loop power control. 
SIR Target is given in the unit UL_SIR_TARGET where: 



UL_SIR_TARGET = 000 
UL_SIR_TARGET = 001 
UL_SIR_TARGET = 002 

UL_SIR_TARGET = 254 
UL_SIR_TARGET = 255 

Value range: {-8.2.. 17.3 dB}. 

Granularity: 0.1 dB. 

Field length: 8 bits. 

6.3.3.9.3 Spare Extension 

Refer to subclause 6.3.3.1.4. 



SIR Target = -8.2 dB 
SIR Target = -8.1 dB 
SIR Target = -8.0 dB 

SIR Target = 17.2 dB 
SIR Target = 17.3 dB 



6.3.3.10 



HS-DSCH CAPACITY REQUEST 



7 





Number of 
Octets 


Spare bits 7-4 


CmCH-PI 


1 


User Buffer Size 


1 


User Buffer Size (cont) 


1 


Spare Extension 


0-32 



A 



> Payload 



J 

Figure 35: CAPACITY REQUEST payload structure 

The HS-DSCH CAPACITY REQUEST control frame is sent for each priority group to indicate the user buffer size. 
The control frame is sent by the CRNC when the CRNC considers the user buffer status needs an increased buffer 
reporting frequency. This may be sent to signal an event, such as, data arrival or user-buffer discard. This control frame 
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is used to improve user -buffer reporting above the level produced by the user-buffer reporting associated with the HS- 
DSCH DATA FRAMEs. 

6.3.3.1 0.1 Common Transport Channel Priority Indicator (CmCH-PI) 

Refer to subclause 6.2.7.21. 

6.3.3.10.2 User Buffer Size 

Refer to subclause 6.2.7.22. 

6.3.3.10.3 Spare Extension 

Refer to subclause 6.3.3.1.4. 



6.3.3.11 



HS-DSCH CAPACITY ALLOCATION 



Two types of HS-DSCH CAPACITY ALLOCATION exist for the HS-DSCH capacity allocation, i.e. HS-DSCH 
CAPACITY ALLOCATION TYPE 1 Control Frame and HS-DSCH CAPACITY ALLOCATION TYPE 2 Control 

Frame. 







Spare 
bits 7-6 



Congestion 
Status 



CmCH-PI 



Maximum MAC-d PDU Length 



Maximum MAC-d PDU 
Length (cent) 



HS-DSCH Credits 



HS-DSCH Credits (cont) 



HS-DSCH Interval 



HS-DSCH Repetition Period 



Spare Extension 



Figure 36: CAPACITY ALLOCATION TYPE 1 payload structure 

The CAPACITY ALLOCATION TYPE 1 Control Frame describes an allocation that the CRNC may use. When the 
HS-DSCH Credits IE has a value of it signifies that there is no resources allocated for transmission and to thus stop 
transmission. When the HS-DSCH Credits IE has a value of 2047, it signifies unlimited capacity for transmission of 
PDUs. When the HS-DSCH Repetition Period IE has a value of 0, it signifies that the allocation (Maximum MAC-d 
PDU Length, HS-DSCH Credits and HS-DSCH Interval lEs) can be repeated without limit. In addition to this the 
CAPACITY ALLOCATION TYPE 1 Control Frame informs the CRNC about the detection of congestion in the DL 
transport network layer with the Congestion Status Bits. 
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Spare 
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Figure 37: CAPACITY ALLOCATION TYPE 2 payload structure 

The CAPACITY ALLOCATION TYPE 2 Control Frame describes an allocation that the CRNC may use. When the 
HS-DSCH Credits IE has a value of it signifies that there is no resources allocated for transmission and to thus stop 
transmission. When the HS-DSCH Credits IE has a value of 65535, it signifies unlimited capacity for transmission of 
PDUs. When the HS-DSCH Repetition Period IE has a value of 0, it signifies that the allocation {Maximum MAC-d/c 
PDU Length, HS-DSCH Credits and HS-DSCH Interval lEs) can be repeated without limit. In addition to this the 
CAPACITY ALLOCATION TYPE 2 Control Frame informs the CRNC about the detection of congestion in the DL 
transport network layer with the Congestion Status Bits. 

6.3.3.1 1.1 Common Transport Channel Priority Indicator (CmCH-PI) 

Refer to subclause 6.2.7.2L 



6.3.3.11.2 



Maximum MAC-d PDU Length 



Description: The Maximum MAC-d PDU Length IE is used in HS-DSCH CAPACITY ALLOCATION TYPE 1 
Control Frame. The value indicates the maximum allowable PDU size among the MAC-d PDU sizes configured via 
NBAP [6]. 

Value range: Refer to subclause 6.2.7.23. 

Field length: Refer to subclause 6.2.7.23. 



6.3.3.11.3 



HS-DSCH Credits 



Description: The HS-DSCH Credits IE is used in HS-DSCH CAPACITY ALLOCATION (TYPE 1 and TYPE 2) 
Control Frame. In case of HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame, it indicates the number of 
MAC-d PDUs that a CRNC may transmit during one HS-DSCH Interval granted in the HS-DSCH CAPACITY 
ALLOCATION TYPE 1 Control Frame. In case of HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame, it 
indicates the number of MAC-d PDU [FDD - or MAC-c PDU] octets that the CRNC may transmit during one HS- 
DSCH Interval granted in the HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame. The number of MAC-d 
PDU [FDD - or MAC-c PDU] octets is retrieved by multiplying the maximum MAC-d PDU length [FDD - or the 
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maximum MAC-c PDU length] (indicated by the Maximum MAC- d/c PDU Length IE) with the number of MAC -d 
PDUs [FDD - or MAC-c PDUs] (indicated by the HS-DSCH Credits IE). 

Value range: {0-2047, where O=stop transmission, 2047=unlimited} in case of HS-DSCH CAPACITY 
ALLOCATION TYPE 1 Control Frame, {0-65535, where O=stop transmission, 65535=unUmited} in case of HS-DSCH 
CAPACITY ALLOCATION TYPE 2 Control Frame. 

Field length: 11 bits in case of HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame, 16 bits in case of HS- 
DSCH CAPACITY ALLOCATION TYPE 2 Control Frame. 

6.3.3.11.4 HS-DSCH Interval 

Description: The value of this field indicates the time interval during which the HS-DSCH Credits granted in the HS- 
DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame may be used. The first interval starts 
immediately after reception of the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame, 
subsequent intervals start immediately after the previous interval has elapsed. This value is only applied to the HS- 
DSCH transport channel. 

Value range: {0-2550 ms}. Value shall be interpreted that none of the credits shall be used. 

Granularity: 10ms. 

Field Length: 8 bits. 

6.3.3.1 1 .5 HS-DSCH Repetition Period 

Description: The value of this field indicates the number of subsequent intervals that the HS-DSCH Credits IE granted 
in the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame may be used. These values 
represent an integer number of Intervals (see subclause 6.3.3.11.4). This field is only applied to the HS-DSCH transport 
channel. 

Value range: {0-255, where 0= unlimited repetition period}. 

Field Length: 8 bits. 

6.3.3.1 1 .6 Spare Extension 

Refer to subclause 6.3.3.1.4. 

6.3.3.1 1 .7 Congestion Status 

Description: The Congestion Status Bits are used by the Node B to indicate whether a congestion situation is detected 
in a DL transport network layer or not. The Node B provides the congestion status in every HS-DSCH CAPACITY 
ALLOCATION (TYPE 1 or TYPE 2) Control Frame, which the CRNC may use. 

Value range: 

No TNL Congestion 

1 Reserved for future use 

2 TNL Congestion - detected by delay build-up 

3 TNL Congestion - detected by frame loss 
Field Length: 2 bits. 

6.3.3.1 1 .8 Maximum MAC-d/c PDU Length 

Description: The Maximum MAC-d/c PDU Length IE is used in HS-DSCH CAPACITY ALLOCATION TYPE 2 
Control Frame. The value indicates the maximum allowable PDU size in number of octets among the MAC-d PDU 
[FDD - or MAC-c PDU] sizes configured via NBAP [6]. 

Value range: {0-1504}, - not used. 
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Field length: 1 1 bits. 

7 Frame protocol error handling 

A received frame protocol frame with unknown Information element or with illegal Information element value shall be 
ignored. Frame protocol frames sent with a CFN in which the radio resources assigned to the associated lub data port 
are not available, shall be ignored. 

7.1 Error detection 

Error detection is provided on frames through a Cyclic Redundancy Check. The CRC for the payload is 16 and for the 
header and control frames is 7 bits. 

7.1.1 CRC Calculation 

The parity bits are generated by one of the following cyclic generator polynomials: 

gcRci6(D) = D"' + D'^ + D^+l. 
gcRC7(D) = D^ + D'' + DVl. 

Denote the bits in a frame by aj , ftlj , 6(3 , . . . , a^ , and the parity bits by p^, P2, p^,. .., p^ ■ A, is the length of a 
protected data and L, is 16 or 7 depending on the CRC length. 

The encoding is performed in a systematic form, which means that in GF (2), the polynomial for the payload. 

aiD^'^'' + a^D^^'^ +... + a^D'^ + p,D'' + p^D'^ + ... + p,,D' + p,^ 
yields a remainder equal to when divided by gcRci6(D), the polynomial for the header and control frames. 

a^D^''^ ^-a^D^^ + ... + a^D^ + p^D + P2D + ... + p^D^ + p-^ 
yields a remainder equal to when divided by gcRcvCD). 

7.1 .1 .1 Relation between input and output of the Cyclic Redundancy Check 

The bits after CRC attachment are denoted by b^,b2,b^,. ..,bg , where Bi=Ai+Li. 
The parity bits for the payload are attached at the end of the frame: 

b^ =ak k= 1,2,3, ...,A,- 

bk = P(k-A;) k = Ai+ l,A, + 2,A, + 3, ...,Ai + L, 

The parity bits for the frame header and the control frames are attached at the beginning of the frame: 

bk=Pk k= 1,2,3, ..., Li 

bk = ^(k-Li) k = L,+ l,L, + 2,Li+3,...,L, + A, 
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